Mulrics Technical BuJietin 



To: 



Distribution 



From 1 



SjoJ ec t * 



MjI fics jdtaOaie Management Facility 



Oa tfc : 



01/10/73 



IhiS HTS proposes an overall design approach for 3 caTabas^ 
management facility for Mu) tics» Tne proposals set forth hare 
shall be rns topic of a Review Meeting to be hela at Camoruje 
(CISL) during the week of Feoruary 10* 1^75* Any questions o~ 
comments can be sent to me via Multics mail (Fnesen Multics). 



MTU- 



Page Z 



Multics Jotdoase Manager Preliminary Program Specifications 



i. Intro auction 

This uocum^nt proposes an overall ae^ign for th= Multics 
Oa taoase Manager (OBM) • It discusses the phi I osophy of the Q3M, 
presen ts a ae scr io ti on of the sof tnare includea as part of the 
system 'ana sets forth design joals. If is intended that this 
aruf t will oe . cohsi aered a focal poin t for discussion of possible 
revisions or enhancements to the j;*M, our of which will emerge 
The find! program specifications* 



1.1 Purpose 

Tne Multics JBM ohaJl oe aesigned 

-to provide tne user with a logical (rather than 

physical) view of the dataoase. 
-to allow dynamic reorganization of the datacase with 

as little effect as possiole on the applications 

using the aataba^e. 
-to provide the user with simple, versatile ana secure 

access to the Odtuoase* 
•to allow definition of tne aataoase oy means of a 

□ ata description Language (DJL)« 
-to allow manipulation of the aata witnin the dataoase 

oy means of a Oata Manipulation Language (UML). 
-to provide the user witn some means of recovery and 

r - 5 t a r t • 

-to pro viae the user witn the advantages cf " I-D-5 
II-liKe c apao i lities." 
Tne purpose of tne Multics D8M is ro provide an integrates 
Set of functions to support the description ana processing of 
large aataoaseS for the business, academic ana governmental 
c c mm on i T i • 

1.2 S^f Twa": Design Philosophy 

Several factors have influenced the overall design philosophy 
ol the proposea UdH* The following factors a^e of special 
s i g.'i i f i can ceJ 

* e n v i * o n m a n f 

The 06M shall operate as a Multics 
suDsystem using the Multics file system tc 

advantage ana shall be written in the PL/1 

programming language. This will provide 

ease of program maintenance as well as 

consistency with otner Multics software. 
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-language interfaces 

Ratner than extend The jyntax of any host 
language, the UML will be aesigr.ca to 
interface with its host languagt via the 
GALL statement. This will provide 3 
relatively simple interface mechan i 3m an 3 
avoid the prooJem of modifying the nost 
I an guage. If>i tidily this interface will 
oe provided for PL/1, b^t if couM easily 
oe extended to include FORTRAN and COBOL. 

-similarity to I-J-S II 

A prime cons i:Jera t i on is to offer the user 
"I-J-3 II- line capabilities." This has 
□ een interpreted in a general sense. Tne 
user wi I I oe provided' with tne general 
functionality of I-D-S II wnich includes 
tnosfc functions "re^troj to suppor r th^ 
description* mam pu I a ti on , restructuring, 
r^covnr^^ security, a na analysis of a jst3 
oase . " P» o) . 

Specifically, tne dataoase on wnicn the OBi'i 
operates snail d c capable of supporting 
singular, n ier*ar chi ca I ana network data 
structures* 

-data independence 

Data independence is a Key objective of the 
06M. Consequently, the concepts of schema 
and suo- scne ma s have been utilised. Also 
contributing to dati independence is the 
use of context yariooles to reference dsta 
elements logically from within tne DHL. 

-database -»eor gan iza t i on 

The Q3M shall ce designed so tnat 
reor gani2 a t * on of the dat aoase ( i • e . » 
rec 1 us f er mg) , as well as restructuring of 
the data shall not oe a costly and fimt 
consuming process. Fur thermo~e , dafaoas^ 
reorganisation shall have a minimal effect 
on user application programs wnich us= the 
database. 

•recovery 

Database rhZo\/tir^ and dataoase integrity 
are two more key objectives of tne 03M. 
Consequently* tne OsM shell include 
provisions for manually "c I eanpoi n r i n the 
oataoase. This will allow for "clean" 
database aum^s to tape ana provide 
assurance that tne integrity of a database 
is not impaired during recovery of fn«= 
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1.3 ttuJtics anj I-O-S II 

The- implementation of 1-0-3 II on rhe Multics system ha^ 
oee'< consx JcTc J ro be a aesiraolt obj ecti vt. This woul j seem To 
oc True only it I- 0- S II is defined in The most general of Terms. 

Sotfie II features seem ro oe at variance wiTh The 

philosophy if Multics operatinj proceduresi 

- 3 h a i n s 

Ine concept of "chaining" records Together forces a 
conSiJ3"aOl e degree of "hara To change" strucTure onTo a 
uaraDase # For instance, it is quite difficult in I-O-S II 
To declare an existing record type to be a new memoer of an 
existing set « The imposition cf This sorf of permanent 
external structure seems to run counter to general MulTics 
philosophy. In Multj.cs The actual binding (i.e., 
structuring) of dara is usually conceirfea of as a dynamic, 
rather than a ^fafic, process. The "oinding" of Jotj 
clsnienrs is usually postponed until the last possible moment 
( a r execution timet for example). Aomit redly oata elcfr.snts 
Ui o database must be structured to a highe~ aegree mar: 
non- OotoOdSe elements because of tne necessity, withi^ a 
aarabase, to carry along (or "rememoer") relationships. 
Ne ver t ne I ess, it _eerns advisable to allow such relationships 
to De as dynamic as possible. 

Tne "chaining" of records also tends to lose much of 
its usefulness as tne chain pointers become more 
interpretive. That is, the most efficient chain pointers 
arc those wnicn are hardware oriented. But it is nor 
realistic to think in terms of hardware oriented chains 
wiThin the framework of the Multics virtual memory system or 
the Multics file -.ysfem. 

I on se que nt I y , the entire concept of "chaineo " records 
seems to be of only limited value with reference to the 
Multics operating environment. 

-ft re as 

Ihe concept of "area" , as used by II, seems well 

sui teo to I-J-S where it is necessary To "reserve" a number 
of file pages ^rior to usage because the CALCing algorithm 
is dependent upon the total number of file pages assigned to 
th- file (or area, or database). The concept is also a 
"natural" for ooOS users wno nave become accustomed to think 
in terms of reserving f Me space before uc Tua 1 I y using the 
tile. 
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The "area" conceotj however, seems alien to the 
philosophy of Multics wherein "file space" (or virtual 
memory) is allocates and used as nee Jed. 

There are some inherent shortcomings in I-Q-i II which ought 
to be avoided if at all possible. Tnese Disadvantages are 
essentially tne same as those listed in I3M*s critique of 0BT3 in 
the "Position Paper ppciented to the wiuuAiYi. Programming Language 
Committee" dated May, 1971. They may oe grouped under three 
general headings . of data independence, dataoase r e or gun 1 z a r i or, 
and .□ML complexity. 

-Oara independence 
The required areas of correlation oetween the user's DML an j 
tne schema OOL are numerous. For example, tne format of a 
FIND statement is dependent on the location mode with which 
the sought-afte^ re cor a was originally stored on the 
database. inch a close association oetween DDL and QML 
means tnat database reorganization will more than liKely 
impact user application programs. This is an unattractive 
implication. The in f er-re I a t i on shi p oetween DML ana scnema 
DDL contributes toward a tendency to restrain the natural 
evolution of tne database structure. 

-Darabose Reorganization 
J ne reorganization of an I-O-S dataoase generally strikes 
fear n the heart of a user. Not only is the process costly 
ana time consuming, out it may also Seriously affect various 
user programs. Nonetheless, it is on I y re asonao I e to expect 
tne type of demands maoe upon a dataoase to cnanye as time 
passes. As these changes aevelop, tne database will unaergo 
some transformation in appearance. It tne transformations 
are such as were not allowed for during the initial I-J-o 
database design period, tnen reorganisation, regardless of 
cost, becomes a necessity. If instances of a a taoa se 
reorganization a~e necessary, they ought at least to be made 
as pail J ess as possiole. 

-OML Gomp I e.xi t y 

The complexity of the I-u-S II DML is immediately oovious to 
anyone who cares to examine tne language syntax ana rules- 
Such complexify is pardonaole if the advantages gainea 
thereoy are sufficient to offset tne associated 
ai Sadvan tages. If seems, however, that the only real 
advantage gained oy this approacn is that user application 
programs are allowed to capitalize on their Knowledge of 
physical storage i ai osyncrac ies (sucn as whether a record 
was stored via the GALC location mode). On the ctnar hand, 
tne aisa dvant ages of such a complex OML include tne loss of 
some data independence, an incr^a^^ in costs of debugging 
and 1 mp I emen t i ng user application programs and a forced 
commitment on the part ot the user to oe content witn a 
relatively static ana unchanging database structure. 
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Attempts s h o u I d oe ma Ja to overcome these obvious 
disadvantages of the I-O-S approacn, while at the same time 
avci.di.nj the inTraJucti^n of other more serious shortcomings* 



2. Udrt Operating environment 

In.; Multics U3M i a to run as a Multics subsystem and will 
u^e rn= standard Multics file system, AH oataset I/O will o c 
performed by the vfile_ I/O module. 



3. Ua fauaoe Management System 

The UBM Will con Si st ot essentially three distinct parts* 

-tnose modules concerned with schema definition ana 
orocess ing. 

-those moJuies concerned with suo-schema definition 
3U processing. 

-those modules concerned with run- time processing and 
data manipulation* 

Additionally tner = will exist utility programs ol various types. 

All u3li activity Will involve interaction Pet ween tne 
Muirics f*le system au user programs. 

Design jo\ *. c t i ve s* 

-The uJ fl shall De designed to allow the user as mjen 
data independence as possiole. 

-uatabase reorganization shall be a function of a 
"database administrator" and shall not affect user 
application programs. 

-Data redundancy shall De kept ro a minimum, ceing 
quire J only to a very limited extent by the 
bntity_keys (defined oelow). 

-The j. A LL interface fo~ the DML will make the 0 
~un-time routines easily available to programs written 
in languages other than PL/1. 



3.1 DataDaSe Structure 

The- r 0 w database will consist of a set of relations ifiles) 

in fnirj Normal Fur m as defined oy £• F. Codd. The only n on- data 

attrioures contained within the dat<a__r e I a r ions shall de the 

unique identifier generated oy tne QBM for in ter- file linkage 



Page 7 



purposes within the Mulfics file system. All file:; cr c ate1 cy 
The DBM shall ^ created oy the Multics file system. Hence* they 
will De 3" ; -tree files js ue fined oy 0 • Knufn. 



3.2 File Handling Procedures 

Lief aha f i ons S 

LLla is a Multics Indexed Sequential File. 

| a t ion is a collection of entities. It can be 
visualized as a two-dimensional taole wherein the 
entities arc the horizontal rows. been relation is a 
1u I tics file. 

entity is a collection of j t f r ibute- I je pair; 
established at schema oefinition time. 

Aiir_i.p_iiie_ is analogous to " t m I a name"' ono may oe 
visualized as the columns of u relation* tstaolisnej 
at schema definition time. 

i£-i— £ i3 a quantity associated with each occurrence of 
an a t tr i out e • 

iklT ity_Ktjy. is rhe logical attrioute (or collection of 
attributes) which uniquely defines each entity. 

iaiHjd_D.5i.ih is a linkage Detween tne entities of two 
relations. A one-way en tr y_pa th a i I ows passage from 
ai entity in da f a_re I a t lon-A to an associate entity 
in daf a_re I at i on-LJ. A two-way enfry__oath f; I I vws 
passage as well from the entity in da ta_re I a t i en- 5 to 
the associated entity in da ta_re 1 a t i on-A . 

Si-SLC^ refers to the suo-scnama definition of ore or 
uore entities. If is the logical representation of a 
group of attributes as seen oy the jser awl icafion 
program. 

Fi_U. refers to the sjo-schema definition of an 
attrioute. If is tne logical representation of an 
attribute as seen oy the user application program. 

As a general rule there will exist 

-one Multics file for e^cn normalized relation. Tni3 
file shall contain all the attribute values of each 
entity in the spec i f i e d re I <* r i on • Each entity shall 
de a logical record within the Multics file. uocn 
entity snail contain one (or a numoer of) 
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attribute (s) constituting an entity_hey. The 
= ntity__Key snail oe i/iiiate to the user only if it hss 
o fieri explicitly oe f inej by tne user* Each, user 
visiole entity Key shall provide the user with a 
"'nan dies" for that entity, Eacn entity shall also 
contain one attribute (invisible to the user) entitles 
3 unique_i j. For those entities witnout a user 
visible entity_key, the unique_iJ jttrioute shall ola/ 
tne role of an entity_key recogniZuOle as such by the 
D8M. Tne unique_id siall contain a unique bit 
representation (generated by the D r JM) which will serve 
as a system identification tag for each entity. 

For exumple, a name_address entity with an entity_Ke/ 
of per son_n jrne might be representee as to I I ows* 

attrioutess person_name str_auur c±ty st unique_id 
entity! 3mith Jodn 101 £ I m A) c AZ f(t) 

wnere f(tJ is a unique function of t and 
t represents the time of entity creation. 

This relation shall De teamed a da ta_re I a 1 1 on • 

Properties of data_re I a t ions 

<> there Will exist one data _r elation for each 
normalised relation, 

<> iach entity within a Oata_re i at ion will ce 
assigned a unique_id. 

<> each enfity_key witnin a da t a_r e I a t i on must oe 
unique within that do ta_r e I a t i on . 

<> the da f j_re I a ti on will De an indexeo sequential 
file indexed on ascending entity_keys. 

<> the only user— visible entry points into a 
dd t a_r e I a f i on are tne entity_key3 explicitly defined 
as such at schema creation time. 

<> if a da t a_re I at ion is not to be entered directly 
by a user (i.e.* if it is to act as a secondary 
record-type in I-D-S t er mino I ogy) » then the 
unique_id attribute for eacn entity shall also be 
the entity_key for that entity? such a da ta__r e I a t i on 
shall require no associated key_re I at ion ( def i ned 
oe I o w ) • 

<> the entities within a data_re 1 a ti on Will contain a 
fixed numoer of attributes (at leosr in the initial 
imp lenient a tion) • 
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3ae Multics file for each dot a_re I a r i on containing a 
wistr visiDle entity_key. This file; shall contain only 
tne unique_id and The enfity__key of rhe soecifieo 
des Td_r& I a t i on. This file snail be indexed, in the 
iultics file system, according to the a t Tr i bu r t _va I ue 
df tne unique_id for each entity. This provides a 
system- interna I I ink^ge mechanism amony the various 
relations. For those da ta__re 1 a t i on s where tne 
jnique_id ana er,tify_Key attrioutes are identical, 
ther^i snail <--xist no key_r a I a ti on. 

Tnis file shall oe termed a key__re I a t i on • 

Properties of ke y_re I a t i on s 

<> the only two affricates of an entity within a 
htiY _re \ at ion will be the entity-key and its 
associated unique_id« 

<> the key_relation will be an indexed sequential 
file indexed on tne unique_id of tne associated 
entity. 

<> -.■■there- Wx I I exist one Key_relati.cn for each 
da f a_r e I a f A on , with a user visible enfity_ke/, to be 
logically associated with anotn&r da f a_re I a f i on • 
That is, if an entity within a data_r el a t i on is To 
oe retrieved when its entiry_key is unknown, then 
there must exist a key_re I a f i on f or tha t 
dafa_re 1 a tion. 

<> the^e will be «s many entities within a 
key_relation as th-cre are entities within The 
associated da t a_re I a t i on . 

one Multics file for eacn one-way entry path into a 
relation. tach of these files shall contain two 
classes of attributes, co^sistinj of the unique_id for 
the source entity and a variable number of unique_ids 
for tna target entities. This file snail be indexed 
on the unidue_id of rhe source entities. In addition 
to the entity_key attrio^jtet there will exist one 
attribute for each target enfity associated with the 
source entiry (ioenfified by the entify_key). Tt~us 
will enable the Treatment of hierarchical and networK 
relationships between different da Ta__re I a f i on s . 

Tnis file snail oe called a cross_re I a Tien. 



Properties of cross_re I a ti on a 
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<> there will exist one cross_re I a t i on for each 
entry_path between two da ta_r e I a t i on s • For example* 
if an employee oa f a_r elation is such that if will 
always oe entered from a department oa ta_re I a t ion 
and f ne Jepartment data_re I ation will never be 
entered from the employee da f a_re I at i on (e.g., giver 
an employees name* there will never oe an attempt 
to retrieve; that employee's department name), then 
we may say there exists a one-way entry_path between 
the employee and Jepartment jata_r e I a t ions. 

<> there will exist as many entities in a 
cross_re I a ti or, as the number* of entities in the 
associated suurce Jata_re I ati on. 

<> each entity within a cross_ra I a t i on will consist 
of two classes of attrioutes, as follows* 

itne umque_id of the entity in me source 
data_re I ation shall constitute tne indexed 
sequent ia I ' Key (or index) 

ithe un±que__ids of those entities in the target 
da ta_re I a t i on snail constitute the non-prime 
(i.c.i non enfity_key) atrrioutes fc* each 
cr oss.r e I a t i on entity. Tnere will exist as m a ny 
target unique_id attributes as tnere are entities 

'associated, with the specified entity in the 
source oa ta_re J at ion. If the source 
oata_r i I a t i on has no user Visible entity_keys» 
fnen the target uniqje_id will also oe an 
en tit y_key va I ue • 



Note that it is possible from tne user's point of view, 
tor all entities within a given dat a_re 1 a t i on to oe associated 
wi n two o^ more i n t r- Jepen Jen t entity_keys from other 
J5 ta_re I a t i ons. Tnis is roughly analogous to the concept of a 
ouconaary detail r^cjra with two master record- type s in I- D- S . 
Of course there is no need for the user application program to 
be cognisant of the different oa t a_re I a t i ons — that is the 
proper concern of the database administrator. Nevertheless, an 
example of the aoova mentioned condition would De an entity 
wnicn Lr\^icats$ the quantity of different purrs committed to 
^nous projects. (This corresponds to a secondary record with 
two masters of different r ecor d- t ype s , in 1-0-3 jargon.) Since 
iucn jn entity would possess no entity_Key visible to or 
knonaole dy the user, its inJex key would oe generated oy the 
0>JM as a unique string. 
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3.3 Schema Processor 

fhe schema itself shall Je>c*iot a database physically 
arranged in a relational {i.e.* taDular) manner, Tne essential 
functions performed ay the schema processor will oe two* 

-it will create, modify and delete all files 
necessary to represent the data as. defined oy 
declarations within the Schema Prccesso~. 

•if will store information aoout the schema 
structure, to be used later oy the SvJb-schema 
Procc ssors 

The specific functions performed oy tne Schema Processor 
snail be to! 

-create a directory file identifying the database 
with a given schema name. Wnen suo-scnemas are 
suosequently created, their names sn a I I ce recorJed 
in tnis direct or y* 

-maintain a list of all attrioufes and entity_key; 
along with the (Multi.cs) file names of the 
data_rel at ions in which they participate. The 
physical characteristics of each attribute (e.g., 
size, type, etc.) shall be described as a part of 
this list. The locks to Oe assigned to each 
attribute sha II a I so be a part of this list. 

-maintain a list of a 1 I da ta_r e I a t i on names along 
with tne attrioufes, lochs ana entity.. keys 
associated with each of them. 

-maintain a list of all the c n t i f y_pa th* existing 
dining all daf a_re 1 a t i ons . An indication whether a 
daf a_re I a f ion is dependent upon another 
da ta_re I a fion will appear in thi_. list. (When an 
enfiTy is added ro or deleted from a dependent 
dato_re 1 at Aon, then the cros s_re I a t i on files between 
the associated da ta_re I a tion s must oe updated. 
Otherwise, the cr o ss_re I a ti on files would Qe updated 
only if the associated da ta_re I a fi on s were 
referenced by the sub-schema in use). 

m scisrna may be as complex or as simple as desireo. Care 
should be taken, however, to insure that it is normalised, 
tlse, considerable inefficiencies could 1 be introduced into a 
use** application program which attempts to modify data. To 
d~aw a rough analogy with I-D-S, normalization of a relational 
database might oe compared to defining a database in terms of 
data structure diagrams. 
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3. i* Sub~schema Processor 

Sub-schema shall provide the user apol i cat ion program 
view of a database. It shall oe a suoset of a schema, 
application program snail oe allowed to access more 
sub- schema and/ or schema s. 

In interfacing with The schema* The 3uo-schema Processor 
need only oe aware of the name of the schema(i.e», the 
database) and the names of those attrioutes (and evtity_Keys) 
with whicn this aub-scnema is concerned. Irs general it shall 
unnecessary for the user of tne Sub-schem a Processor to oe 
concerned with the names of the d at a_r e I a ti on s » Ke y_re I a ti on s 
o" eras s_r.e rations* A general Knowledge of tne logical 
relationships among The attributes will usually suffice. Tne 
Sub-schema Processor will update tne list of sub-schema names 
associated with this schema* 

A Sub-schema DDL shall oe defined, initially* tor the PL/I 
programming language. 

S pec i f i c f unc t i ons performed oy the Suo-schema Processor 
snail include the following: 

-the associated schema directory file snail oe 
updared to contain the entr/ name of the specifics 
suo-sche ma • 

-a list shall be maintained which shall associate all 
the logical database records definej in the 
sub-schema with the specified enTi ties def ineo by 
The Schema Processor (There need not be a one-to-one 
correspondence). A list of suo-schema specified 
locks shall also be maintained. 

-a list snail be maintained which associates field 
names defined in the suo-scnema wiTh specified 
attribute names previously defined in the schema. 
This list shall also contain a description of the 
physical characteristics of each field defined by 
the suD-schema. These characteristics may differ 
from the characteristics of The corresponding 
attribute defined in the schema. The OBM will m-jhe 
the necessary data conversions at run-time. A list 

Of I JCKi tO Oe applied a^dinst each field Shall SlSO 

bemaintoineo. 

-a report showing any inconsistencies (such <es 
missing entity_hey definitions within the 
subschema) will oe generated. Also? if an entity 
referenced oy tne suo-schema whicn is dependent 
to an entity in another dat a_r e I a t i on , then whenever 
a dependent entity is added to or deleted from the 



T h e 
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JaTasasej a "hidden" cro ss_re 1 a 1 1 on file must be 
updated. All possibi I it i t 3 of such "hiaaen" side 
effects snail be reportej out. 



3. b uata Manipulation 



The JML shall be implemented throujh the use of CALL 
statements. The following functions will be supported: 

-OPEN 

make a sub- schema ava i I ab I e for update or 

retrieval- on 1 y (all necessary files, such as 

da ta_r e 1 a f i on s» key_re I a f i on s and cr oss_re I a f i on s , 

shall oe attached anu opened by the OBM run- time 

routines — provided rhe user has access to all the 

files). 

-STORE 

a new record with all its fie las {which may oe nail 
valued) will be placed on the Oataoase -- the user 
must provide a non-null entify_key and its value 
as well as the fiela names and values to ce 
associated with the specified record . 



-FIND 

retrieve a specified record and its associated 
fielo Values as defined oy the sub -schema. 

-MODIFY 

modify 3 specifies recoru or field value(s) to 
equal a given set of values. 

"Qc.LE.Tc 

remove from the dataoase a specified record or 
field vslue (s) satisfying a given set of 
conditions? also remove all relevant linkages. 

-CLcANPOINT 

the segments within the suo-schema whicn have been 
altered since the last £L£ANPQIf4T command was 
issued shall be made eligiole to be dumped to tape 
with tne iiultics Backup facility. 

-CLOSE 

the sub-schema shall be releaseu from the user 
application program (all associated tiles snail be 
closeu and uefached). 

Additional functionality*, sucn as algeoraic operations, 
may be aaoed at a later time. However, it may oe aovisaole for 
sucn capaoilities to oe provided by separate 
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enj-user-f acilities, rather tnan through PL/1. A primary 
feature of the DHL snail be that ail references to attributes 
will be on the logical level. The user need know little about 
me physical organisation of the database. AM references to 
data will oe through the field names as defined by the user's 
suo-schems. The concept of "current logical record" shall oe 
implemented. It shall refer to tn e last logical record of -.-ach 
type (as defined in the suo-schema) to have been operated on oy 
a SfUftE or FIND function. These records* however, shall not be 
explicitly referred to as "currenr" records. They shall be 
r« t~ i. e v« 3 oy use of rne FINJ function with an argument to 
indicate "first," "next* or "all' records satisfying some 
c^-no i t i on . 



3.6 operational Considerations 

- Re c o v e r y / In t e gr 1 1 y 

A means of insuring dataoase integrity shall 
oe an essential part of the system. The OBH shall 
take cdTc to update ail linkages whenever a datum 
is modified oy a user application program. If 
desired, "oefore" and/or "after" images of all 
altered segments could oe journalized oy being 
written to auxiliary files and dumped to tape 
periodically using the Multics oAoKUP facility. 
Tne overhead for such protection may be high. It 
ii not clear at tnxs time how much should oe 
provided in this area. 

Anotner possibility is that all updates be 
written to a reserve a^ea before actually oeing 
"posted" to tne dataoase* Again, tne overhead 
price for such a procedure would oe considerable. 

Lonj 1 ^rwi r ^cosj ery procedures must also ce 
provided for those instances when part of the 
database is inadvertantly destroyed. The backup 
tapes can oe used to oring such a destroyed 
oataDssc back up to its current state of integrity. 
This requires, however, that the backup tapes 
contain "clean" data. This oecomes especially 
relevant when dealing with mu I t i - ae gmen t files, 
since GbM linkages in one segment may reflect a 
different state than those in another segment. To 
this end, the DdM must estaoli^n some intelligent 
communication interface witn the 0 AUKUP facility if 
if i s to be used to advantaje. Us«r-ini tiated 
CLlANPOINTs will contribute toward such a goal. as 
wi ll UdM initiated CLL ANPOIMTs. Tne DBM wi I I dump 
updated segments only after if has assured itself 
that all segments to oe dumped are in a CllANPuINT 
state. 
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-Privacy/Securi t/ 

Tne U8M shall rely on ma ri I y on Access Control 
Lists to insure privacy on the schema, sub- schema 
ana relation levels. T n i s snail fall under the 
responsioi i i ty of the DataDase A aminx ^tra f or . 
Provisions will oe made to provide the future 
capaoi I ity to LUCK and UNLOCK items at the 
attribute level, 

-Concurrent Update 

Concurrent update of a sub-schema shall not oe 
protected. This feature may ce provided in tne 
f utur e . 



OiiM Support Software 

The support software to be provided shall include 
utilities to load, recover d analyse a jafaoase a„ well as or 
ei d-user- facility. 



4.1 Load and Unload Utility 

The Load Utility* written in PL/i, shall oe designed tz 
run uo an absentee process, which will accept parameters 
de fining tneraw data to be loaded. The Load Utility will 
generate all necessary Ufuque_ias and Will load all relevant 
linnage files (which will previously have been create! by the 
Schema Processor). The database referenced by the LoaJ Utility 
snail De tnaf dataoase defined by th schema (rather than a 
suo-schemsi . The LDad Utility shall normally oe tne 
r c spanziQ i J i t y of tne dataDase administrator. 

iht Jnlocid Utility shall by designed to dump to race sH 
o~ selected portions of a dat aoa s e, inc i ud ing a I I r e levant 
system j a ta such as pointers and directories. 



4. 2 Recovery Ut i I i t y 

The Recovery Utility shall interface wifn tne Mult^cj 
BACKUP facility to provide for "clean" daraoa^e recovery. The 
recovery snail oe as automatic as possible. 



i+.3 Analysis Utility 

^ Utility to ar\& ly*.*; tne Size of datu_relations, 
ke y_r e I a f i ons and cross_re la t ions snail be provided. Tne 
Analysis Utility shall also serve as a verification ai3 in 
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determining The existence, or lack tnereof? of linkages fcetdeen 
tne entities of various oa ta_re 1 a ti ons. 

h*k tn d- JScr-Faci 1 i t y 

Some type of en J-u^r-f dci I i Ty shall be proviaej at some 
fiina. Ihis facility snail include out not oe limited ro the 
to N ow i rial Capao i 1 1 t 1c sJ 

•BojI tidii retrievals 

- c omputa t i on s 

- sor tn^ 

•creation of aggregate data sets 
- ~ epor t generation 



<+.i> instrumentation 

Some provision should oe made for measuring 08M per f armancc # 
Sv/fni oovious areas to examine would oe the time required to 
perform overn«ad laoor, such as pointer updating, the time 
rtd-iirej to Retrieve entities par t i ci pa t i n g in different 
structures the time required to responj to a request in an 

interactive environment. 



